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FOREWORD 


The  Center  for  Air  Sea  Technology  (CAST)  research  program  in  FY94  was 
moditied  to  adjust  to  new  Navy  Ocean  Modeling  and  Prediction  (NOMP)  program 
priorities,  especially  in  the  area  of  coastal  and  semi-enclosed  seas.  The  objectives 
were  to: 

•  Conduct  coastal  and  semi-enclosed  seas  ocean  modeling  basic  research, 
embedded  in  a  CAST  modularized  software  system,  with  the  emphasis 
on  model  relocatability  to  any  geographical  region; 

•  Support  the  technical  requirements  of  Navy  and  university  ocean 
modeling  efforts  by  providing  routine  day-to-day  technical  support  to  the 
scientific  staff,  and  by  designing,  developing,  and  implementing  next 
generation  technical  support  capability; 

•  Tailor  and  transition  applicable  advanced  technical  support  capabilities 
developed  for  research  community  to  the  operational  Navy;  and 

•  Strengthen  collaboration  with  academia  by  incorporating  student  and 
faculty  in  CAST  projects. 

In  accomplishing  these  objectives,  CAST  in  1994  supported  1 1  graduate  and 
undergraduate  students,  which  included  two  through  the  MSU  Cooperative 
Education  Program,  three  from  the  MSU  Department  of  Computer  Science,  one 
from  the  MSU  NSF-sponsored  Engineering  Research  Center,  two  through  the 
University  of  Southern  Mississippi  Cooperative  Education  Program,  and  one  each 
from  Oregon  State  University,  Tulane  University,  and  Brandeis  University.  CAST 
also  had  a  faculty  program  with  four  research  affiliates  from  the  MSU  and  Tulane 
University  Departments  of  Computer  Science,  as  well  as  the  MSU-NSF 
Engineering  Research  Center. 

This  technical  note  summarizes  the  1994  research  conducted  by  these 
students  and  research  affiliates.  CAST  was  extremely  pleased  with  the  research 
support  provided  by  these  individuals,  not  only  in  their  dedication  but  in  the 
quality  of  the  research  conducted. 
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Patrick  Perrin 

Ph.D.  Program,  Department  of  Computer  Sciences 
Tuiane  University 

Title:  Design  of  an  Intelligent  Support  System  for  Scientific  Databases 

Objective:  ScientiHc  databases  constantly  and  rapidly  grow  in  terms  of  the  amount  of 

gathered  knowledge.  This  huge  flood  of  raw  knowledge  is  mainly  numerical  data  representing 
observations  (e.g.,  satellite  infrared  images,  ship  and  storm  tracks,  etc.).  It  is  predicted  to  be  of 
the  order  of  gigabit  or  terabit  of  new  raw  data  per  day.  These  fast  growing  scientific  databases 
render  impossible,  even  unfeasible,  human  raw  data  analysis;  hence  the  urgent  need  for 
automatic  data  and  efficient  human-machine  interface.  This  project  responds  then  to  the  need  to 
find  knowledge  in  the  flood  of  data  and  to  efficiently  allow  the  user  to  access  and  use  this 
knowledge.  It  is  then  concerned  in  filling  the  gap  between  data  generation  and  data 
understanding  for  efficient  and  effective  data  exploitation,  such  as  retriev^  of  information  and 
inferences  on  current  knowledge. 

Approach:  The  approach  is  for  the  system  to  discover,  in  an  automatic  manner,  relationships 
among  the  objects  contained,  or  to  be  inserted,  in  the  databases.  This  corresponds  to  finding 
interesting  and  useful  patterns  in  the  raw  observational  data  stored  in  the  databases.  Such 
patterns  represent  an  effective  and  efficient  description  of  the  data.  Transforming  those  patterns 
into  production  rules  to  be  inserted  in  the  knowledge  base  of  an  expert  system,  and  adding  the 
facilities  and  power  of  an  interactive  conversation^  natural  language  interface,  will  allow  the 
system  to  do  efficient  exploitation  of  large  scientific  databases.  Designing  and  implementing 
such  an  Intelligent  Support  System  (ISS)  is  the  final  goal  in  the  research.  The  overall  ISS 
functional  components  are  depicted  in  Figure  1. 


Figure  1.  ISS  Functional  Components 
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This  research  is  also  concerned  with  the  discovery-learning  process  of  ISS.  In  developing  an 
Automatic  Data  Analysis  System  (ADAS),  which  combines  the  strengths  of  two  machine 
learning  techniques,  that  are  data  clustering  and  induction  learning  by  decision  trees,  the  intent  is 
to  generate  production  rules  that  describe  the  raw  data  contained  or  being  included  in  the 
scientific  database.  It  continues  and  enhances  previous  work  in  which  a  system  for  knowledge 
discovery  in  scientific  databases  was  designed  and  implemented  using  data  clustering, 
classification  heuristics,  and  domain  knowledge.  This  previous  system  analyzed  the  raw  data  to 
find  stmcture.  This  was  done  by  partitioning  the  objects  space  into  a  hierarchy  of  clusters,  each 
representing  a  class  of  objects  considered  to  describe  a  similar  concept.  The  clustering  was 
performed  using  some  pre-deHned  classification  criteria  (such  as  object  features),  some 
heuristics,  and  some  domain  knowledge.  This  research  adds  to  this  basic  system  a  set  of 
algorithms  to  make  a  general  description  of  each  cluster.  Such  descriptions  are  expressed  in  first 
order  predicate  logic  as  production  rules.  These  production  rules  are  intended  to  be  used  by  an 
expert  system  for  efficient  exploitation  of  the  knowledge  contained  in  scientific  databases 
(e.g.,  inference  and  information  retrieval).  These  algorithms  are  based  on  inductive  learning  by 
decision  trees  and  automatic  rule  generation. 

The  research  also  involved  the  effective  exploitation  of  the  knowledge  by  the  user.  Discoveries 
are  appropriately  formatted  by  the  system  for  the  intended  user.  In  the  first  stage,  this  is  done  as 
first  order  predicate  logic  rules  obtained  from  decision  trees.  This  is  a  convenient  knowledge 
representation  for  knowledge  manipulation  and  analysis,  and  is  easily  transformable  into  natui^ 
language  for  human  user  data  exploitation.  We  designed  an  interactive  and  robust  natural 
language  conversational  simulation  model  called  ENTRETIEN.  Since  language  is  a  natural 
support  for  human  being  communication  for  transfer  of  information,  ENTRETBEN  will  allow  the 
human  user  to  naturally  communicate  with  the  system  to  efficiently  exploit  the  potential 
information  non-trivially  stored  in  the  large  scientiric  databases.  This  is  to  palliate  the  actual 
obvious  lack  of  efficient  and  effective  communications  between  human  users  seeking 
information  and  computer  systems  willing  to  provide  such  knowledge.  ENTRETIEN  will 
conduct  the  dialogue  with  the  user  by  analyzing  each  user's  utterance  (e.g.,  query,  command, 
etc.)  expressed  in  a  natural  way  (e.g.,  English)  and  in  the  current  context  of  the  conversation  to 
better  serve  the  user’s  needs.  This  is  based  on  human  natural  language  information  seeking 
dialogues  during  which  each  participant  attempts  to  recognize  the  otiier  participant  intention  of 
plans  for  successfully  communicating  information.  This  system  will  thus  interactively  conduct 
the  dialogue  to  recognize  the  user’s  intentions  in  seeking  information  in  the  scientific  numerical 
databases.  We  want  to  base  our  plan  recognition  simulation  model  on  a  previously  developed 
model. 

Results:  A  series  of  experiments  were  conducted  in  applying  ADAS  to  CAST-NEONS,  a  real 
world  scientific  database  currently  used  by  CAST  for  ocean  modeling  and  prediction.  By  these 
experiments,  it  was  shown  that  the  system  was  able  to  identify  automatically,  from  scratch,  the 
Gulf  Stream  in  the  North  Atlantic  area  by  analyzing  and  classifying  measures  of  its  features, 
such  as  salinity  and  temperature.  This  was  done  at  constant  depth  but  we  intend  to  enable  the 
system  to  search  more  interesting  correlations  such  as  salinity,  temperature,  depth,  and  temporal 
variables.  By  these  examples,  we  empirically  demonstrate  the  feasibility  of  our  approach  in 
doing  automatic  numerical  data  analysis. 

This  research  clearly  shows  that  combining  machine  learning  techniques  (data  clustering  and 
induction  learning  by  decision  trees)  with  production  rules  is  an  effective  mean  for  automatic 
data  analysis  of  huge  and  rapidly  changing  amounts  of  observational  raw  data  in  scientific 
databases.  In  terms  of  expert  systems,  automatic  rule  generation  from  non-trivial  knowledge 
contained  in  scientific  databases  eases  the  knowledge  acquisition  bottleneck  that  usually  exists  in 
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extracting  knowledge  from  human  experts.  Further  developments  of  the  prototype  seems 
promising  in  solving  the  problem  of  automatic  data  analysis  for  information  retrieval  in  scientific 
databases. 

We  believe  that  constructing  the  natural  language  interface,  in  which  the  computer  “speaks”  the 
same  language  as  the  human  user,  is  of  great  interest  to  efficiently  exploit  information  non- 
trivially  stor^  in  databases.  We  want  to  go  a  step  further  in  building  an  intelligent  machine 
capable  of  communicating  efficiently,  as  humans  do  naturally. 

Future  Research:  Future  directions  toward  the  goal  of  designing  and  implementing  the 
intelligent  support  system  include  the  design  of  the  knowledge  base  updating  systems,  the 
integration  of  ^e  prt^uctions  rules  and  a  previous  semantic  network  that  captures  the  domain 
knowledge  into  an  expert  system  knowledge  base,  the  implementation  of  EOTRETIEN  for  the 
system  to  naturally  converse  with  human  users,  the  selection  of  better  data  clustering  algorithms 
to  refine  and  render  more  robust  the  knowledge  discoveryAeaming  process,  and  finally  to  encode 
the  knowledge  found  into  a  generic  form  suitable  for  the  knowledge  base. 

Research  Advisor:  Dr.  Frederick  Petty,  Department  of  Computer  Science,  Tulane  University 
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Dongmei  Wu 

M.S.  Program,  Department  of  Computer  Science 
Mississippi  State  University 


Title:  Error  Pattern  Identification  and  Qustering  (EPIC) 

Objective:  Scientists  at  the  Naval  Oceanographic  Office  (NAVOCEANO)  at  the  Stennis  Space 
Center  use  a  numerical  model  developed  by  an  international  group  to  provide  predictions  of  wave 
height  for  the  Navy.  The  model  which  is  called  the  Wave  Model  (WAM)  predicates  significant 
wave  height  (SWl^  based  on  wind  speed.  Comparisons  of  the  WAM  predictions  and  SWH 
calculated  from  altimetry  measurements  have  indicated  that  the  WAM  predictions  are  inaccurate 
in  some  situations.  Because  the  altimetry  SV/H  data  cannot  be  obtained  quickly  enough  and 
because  it  covers  only  a  very  narrow  geographical  region,  the  NAVOCEANO  staff  cannot  use 
this  data  to  correct  the  WAM  predictions.  Therefore  research  on  using  machine  learning 
techniques  to  determine  the  situations  in  which  the  errors  of  the  WAM  predictions  occur  has  been 
initiated  The  objectives  of  this  project  are: 

•  in  the  short  term,  we  want  to  identify  features  which  characterize  the  circumstances  in 
which  errors  in  the  Wave  Model  (WAM)  output  typically  occur, 

•  in  the  long-term,  we  plan  to  investigate  the  use  of  techniques  which  can  automatically 
exam  historical  data  to  identify  the  sources  of  errors,  and  to  associate  a  degree  of 
confidence  with  WAM  data,  and  correct  WAM  output.  We  intend  to  develop  a  general 
approach  which  will  be  applicable  to  a  variety  of  oceanographic  model  validation  tasks. 

Approach:  Two  well-known  clustering  packages,  Cobweb/3  and  AutoClass,  have  been  used  for 
this  project  Cobweb/3  employs  an  incremental  concept  formation  strategy  for  clustering  and 
classification.  It  Erst  forms  a  tree  of  one  class  which  contains  general  concepts  for  observations, 
and  then  discriminates  new  observations  from  the  others  in  an  incremental  fashion.  The  result 
is  a  classification  hierarchy.  AutoQass,  on  the  other  hand,  uses  the  standard  Bayes’  rule  to 
cluster  observations  into  classes.  AutoClass  does  not  build  a  hierarchy. 

NAVOCEANO  has  supplied  one-year  of  data  of  WAM  predictions  and  ERS-1  and 
TOPEX  altimetry  SWH  data  for  the  Mediterranean  Sea.  The  altimetry  data  includes  values  of 
different  features  such  as  longitude,  latitude,  time,  wind  speed,  and  altimetry  SWH.  Values  for 
bathymetry  were  obtained  from  the  (Tenter  for  Air  Sea  Technology.  It  was  necessary  to  extract 
WAM  predictions  that  corresponded  to  altimetry  measurements  in  time  and  location.  After  the 
WAM  data  points  had  been  extracted,  the  difference  (SWH  error)  of  the  WAM  prediction  and 
the  altimetry  SWH  were  calculated  using  the  following  formula  (based  on  the  assumption  that 
the  altimetry  SWH  is  accurate): 

SWHa  =  altimetry  SWH  -  WAM  prediction 

For  the  experiments  described  in  this  report,  data  from  ERS-1  for  a  thirty-day  period  has  been 
used  (every  10th  data  point  was  selected). 

The  two  clustering  algorithms  have  been  applied  to  different  sets  of  features: 

•  longitude,  latitude,  wind  speed,  altimetry  S^^,  SWH  error,  and  bathymetry. 

•  longitude,  latitude,  wind  speed,  and  SV^  error. 

•  longitude,  latitude,  and  S\^  error. 

•  wind  speed,  altimetry  SWH,  and  bathymetrj-  with  SWH  error  respectively. 
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•  wind  q)eed,  altimetry  SWH,  SWH  error,  and  bathymetry. 

The  ejqjeriments  have  been  performed  using  two  modes  of  the  clustering  algorithms: 
clustering  and  prediction.  Data  has  been  run  in  the  clustering  noode  to  see  whether  meaningful 
clusters  can  be  obtained  with  different  features.  The  prediction  mode  is  used  to  determine  the 
meaningfulness  and  effectiveness  of  the  clusters  for  predicting  values  of  certain  attributes.  In  the 
prediction  mode  of  Cobweb/3,  a  set  of  training  data  is  used  to  form  a  classitication  hierarchy, 
and  then  a  set  of  test  data  with  a  missing  attribute  is  classified  based  on  the  classitication 
hierarchy.  In  these  experiments,  the  values  of  SWH  error  were  predicted  based  on  the  other 
attributes.  Training  data  and  test  data  were  different  samples  of  ERS-1  data  for  the  same  time 
period. 


For  both  clustering  and  prediction  modes,  the  experiments  have  been  done  with  both  real 
values  and  nominal  values  since  nominal  values  appeared  to  be  easier  to  analyze.  The  nominal 
values,  such  as  "low"  and  "deep",  are  actually  tags  for  real  values  in  specif!^  ranges.  For  the 
current  data,  the  real  values  of  each  attribute  have  been  converted  to  nominal  values  using  pie- 
detined  ranges  which  have  been  approved  by  the  NAVOCEANO  scientists  (Table  1). 


Table  1.  Ranges  Used  for  Nominal  Value 


Attribute 

Value  Range 

Nominal  Value 

Longitude 

-6.0  <  X  ^  0 

VeryLow 

0  <  X  ^  10.0 

Low 

10.0  <  X  ^  20.0 

Medium 

20.0  <  X  ^  30.0 

High 

X  >  30.0 

VeryHigh 

Latitude 

30  <  X  ^  34 

VeryLow 

34  <  X  ^  38 

Low 

38  <  X  ^  42 

Medium 

42  <  X  ^  46 

High 

X  >  46 

VeiyHigh 

SWH 

0.0  ^  X  <  1.5 

Low 

1.5  ^  X  <  3.0 

Medium 

3.0  S  X  <  4.5 

MediumHigh 

4.5  <  X  <  6.0 

High 

6.0  $  X  <  7.5 

Higher 

Wind  Speed 

0.0  ^  X  <  4.0 

VeryLow 

4.0  X  <  8.0 

Low 

8.0  ^  X  <  12.0 

Medium 

12.0  ^  X  <  16.0 

High 

X  2:  16.0 

VeryHigh 
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Table  1.  Ranges  Used  fOT  Nominal  Value  (continued) 


Attribute 

Value  Range 

Nominal  Value 

Bathymetry 

X  <  10 

VeryShallow 

10.0  ^  X  <  50.0 

Shallow 

50.0  ^  X  <  300 

Medium 

300  ^  X  <  1000 

Deep 

x^  1000 

VeryDeep 

SWH  error 

X  <  -23 

WAMVeryHigh 

-2.5  ^  X  <  -1.0 

WAMHigh 

-1.0  ^  X  <  0.0 

WAMJustHigh 

0.0  ^  X  <  1.0 

WAMJustLow 

1.0  ^  X  <  3.0 

WAMLow 

X  ^  3.0 

WAMVeryLow 

We  have  developed  a  new  method  for  analyzing  the  output  clusters  from  experiments  that 
use  real  values  for  attributes.  This  method  uses  a  form  of  inferential  statistics  called  the 
amfidence  interval  of  the  mean.  The  confidence  intoval  is  a  range  of  values  bounded  by  a 
lower  and  an  upper  limit  This  interval  is  expected  to  contain  the  mean  of  the  parameter  with 
a  cotain  degree  of  confidence.  In  the  current  experiments,  the  degree  of  confidence  is  95%.  The 
formula  used  to  confute  the  confidence  intovd  is: 

Mom  ±  1.96  X 

/Object -Count 

For  the  prediction  mode,  the  absolute  value  of  the  differences  of  the  predicted  SWH  errors 
from  Cobweb/3  and  the  original  SWH  errors  were  obtained.  In  order  to  analyze  the  differences, 
different  ranges  [0.0,  0.5],  (0.5,  1.0],  (1.0,  1.5],  (1.5,  2.0],  (2.0,  3.0],  and  (3.0,  ...)  have  been 
defined,  and  the  percentage  of  the  difference  values  that  occur  in  each  range  has  been  calculated. 
For  exan^le,  if  the  range  [0.0,  0.5]  is  an  acceptable  error  range,  and  the  calculated  percentage 
fcH*  this  range  is  high,  thoi  it  can  be  said  that  the  prediction  is  good.  This  allows  us  to  compare 
the  effectiveness  of  clusters  that  are  based  on  different  features  in  predicting  the  SWH  error. 

Results:  We  have  observed  that  if  longitude  and  latitude  are  used  as  attributes  in  the  clustering 
ejqreriments,  the  objects  are  clustered  almost  exclusively  based  on  location. 

We  have  observed  that  when  compared  to  the  ERS-1  data,  WAM  predictions  are  low  in 
almost  all  locations.  The  experiments  have  shown  that  when  the  wind  speeds  increase,  WAM 
predictions  become  even  lower.  Table  2  shows  the  clusters  formed  bas^  on  wind  speed  and 
SWH  OTor.  Our  the  experiments  have  not  shown  that  the  altimetry  SWH  and  bathymetry  have 
strong  relationships  with  the  SWH  error.  The  use  of  all  four  attributes  (wind  spe^  altimetry 
SWH,  SWH  error,  and  the  bathymetry)  did  not  seem  to  yield  more  meaningful  clusters. 
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Table  2.  Clusters  FcHrmed  Based  <Ht  Wind  Speed  and  SWH  Error 


Cluster  Number 

Mean  Wind  Speed  (m/s) 

Mean  SWH  Error  (m) 

1 

13.60 

1.8 

2 

9.40 

1.5 

3 

6.75 

0.7 

4 

4.10 

0.5 

5 

1.63 

0.6 

When  we  examined  the  clusters  formed  using  nominal  data,  we  found  that  the  clusters 
were  not  as  meaningful  as  those  based  on  real  values.  We  speculate  that  this  is  because  some 
information  is  lost  in  the  process  of  converting  the  real  values  to  the  nominal  values. 

For  the  experiments  run  in  the  prediction  mode,  more  than  half  of  the  predictions  of  SWH 
errw  fw  each  experiment  are  within  die  range  of  fO.O,  0.5]  (Table  3). 


Table  3.  Analysis  for  SWH  Error  predictions  for  the  Prediction  Mode 


Attributes  used  in 
clustering 

Percent  of  Predicted  Values  in  Each  Range 
[0.0,0.51  (0.5,1.01  (1.0,1.51  (1.5,2.01  (2.0, 3.0] 

(3.0, ...) 

Wind  Speed 

SWH  Eirm: 

58% 

25% 

8% 

5% 

1% 

3% 

Bathymetry 

SWH  Error 

38% 

21% 

14% 

6% 

11% 

10% 

Altimetry  SWH 

SWH  Error 

53% 

28% 

10% 

5% 

3% 

1% 

^^^d  Speed 

Altimetry  SWH 
Bathymetry 

SWH  Error 

54% 

25% 

8% 

5% 

5% 

3% 

Future  Research:  Our  future  research  will  be  concentrated  on  determining  other  sets  of  features 
which  may  influence  the  SWH  error.  We  will  continue  research  on  our  long-term  objective 
which  is  to  investigate  techniques  which  can  automatically  exam  historical  data  to  identify  the 
source  of  errors,  associate  a  degree  of  confidence  with  data,  and  cc  rect  WAM  output 

Research  Advisor:  Dr.  Susan  Bridges,  MSU  Department  of  Computer  Science 
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ZhifanZhu,  Ph.D.  Program,  Engineering  Research  Center 
Mississippi  State  University 

Title:  Scientific  Visualization  of  Oceanic  and  Meteorological  Data 

Objective:  The  study  and  prediction  of  weather  changes  in  a  global  or  mesoscale  range  requires 
knowledge  of  both  atmosphere  and  ocean  feature  dynamics.  Numerical  weather  and  ocean 
nnodels  have  been  operational  for  many  years,  and  coupled  air-sea  models  have  also  appeped 
recently.  In  parallel,  computing  power  has  dramatically  increased  which  allows  higher  time- 
space  resolution  modelling  with  feature-resolving  capability.  The  potential  data  quantity  exceeds 
h’indreds  of  megabytes  or  even  gigabytes.  Visualizing  features  of  interest  is  essential.  The 
primary  purpose  of  this  research  was  to  investigate  the  visualization  techniques  that  must  be 
efficient  in  automatically  extracting  and  then  visualizing  important  features  from  digital  data. 
The  work  is  considered  as  an  extension  of  previous  research.  It  includes  improving  the  existing 
ocean  feature  detection  algorithm  and  studying  the  meteorology  feattire  detection  methods. 

Approach:  To  meet  the  research  requirement,  a  new  visualization  environment/tooL  envis,  has 
been  developed  from  a  previous  tool,  vis3.  The  internal  rendering  coordinate  system  has  been 
modified  to  allow  visualization  of  either  ocean  data  or  atmospheric  data,  or  both  of  them  at  the 
same  time.  The  internal  data  buffer  has  been  nKxiified  to  be  a  five  dimensional  array  to  suppe^ 
multivariate  time-varying  volumetric  data.  The  feature  detection  algorithms  are  again 
incorporated  into  the  visualization  system  as  supporting  elements. 


Figure  1.  System  Diagram 

A  new  method  has  been  used  to  detect  ocean  eddies.  The  previous  approach  of  ^y  detection  is 
based  on  edge  amplitudes  and  spatial  correlations.  The  new  algorithm  works  with  the  phases  of 
edges.  It  first  locates  the  interior  points  of  a  possible  eddy  by  using  a  'gravity  rule’,  which  can  be 
illustrated  with  an  example  of  phase  pattern  (Figure  2).  For  a  closed  warm  eddy,  the  phase 
angles  along  its  boundary  all  point  towards  the  center  of  the  eddy.  Therefore,  any  interior  point 
of  the  eddy  can  not  be  moved  out  of  the  boundary  without  a  sufficient  force  to  overcome  the 
center-bound  gravity.  For  a  cold  eddy,  the  algorithm  works  in  the  same  way  except  that  all 
phase  angles  need  be  changed  by  1805.  This  method  is  more  reliable  in  detecting  the  eddy 
centers. 

An  equal  amount  of  work  has  been  paid  to  the  study  of  feature  detection  for  meteorological  data. 
As  a  case  study,  a  public-domain  data  set  from  Vis5d  was  used  as  the  test  data.  The  data  set  has 
10  variables,  19  time-steps  in  a  two-hour  interval,  a  35x41x15  grid  with  longitude  resolution  of 
1.6  degrees,  latitude  resolution  of  1.25  degrees,  and  about  1  km  vertical  resolution. 
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Rgure2.  Phase  Pattern  Example 

The  effort  was  focused  on  cyclones  and  the  Jetstream  at  high  altitude.  The  cyclone  is  a  closed 
circulation  about  a  low  pressure  center,  which  is  counterclockwise  in  the  NorAem  Hemisphere. 
The  impcntance  of  und^tanding  the  cyclonic  system  has  already  been  recognized  in  predicting 
and  tracking  thunderstorms.  Such  a  meteorological  feature  is  in  fact  associated  with  multiple 
atmospheric  variables,  such  as  wind,  pressure.  The  algorithm  that  detects  cyclones  (anti¬ 
cyclones)  involves  computing  the  wind  flow  patterns  and  the  vertical  vorticity  field. 

The  Jetstream  is  relatively  strong  winds  concentrated  within  a  narrow  stream  in  the  atmosphere. 
In  NOTth  America,  the  Jetstream  is  of  interest  at  mostly  higher  altitudes  (above  8  km  from  the  sea 
surface).  It  illustrates  the  massive  circulation  pattern  that  governs  general  air  motion. 

Results:  Hgure  3  shows  an  example  of  eddy  detection  with  the  new  phase  approach.  The  data 
is  Gulf  of  Mexico  temperature.  The  horizontal  slice  is  clipped  by  the  bathymetry  (daric  part). 
Two  eddies  are  detected. 


Figures.  Two  Detected  Eddies 

Figure  4.a.  displays  two  detected  cyclones.  The  bottom  is  the  topography  of  North  America. 
The  bigger  cyclone  is  around  the  central  part  of  the  United  States,  and  the  smaller  one  is  at  the 
ocean  close  to  Alaska.  The  cyclone  cores  are  represented  by  the  vorticity  surface.  The  white 
lines  are  the  wind  trajectories  around  the  cyclone  cores.  They  produce  very  vivid  cyclone 
circulation  patterns.  The  Jetstream  is  shown  by  the  strip  with  the  arrow  at  the  right  end 
indicating  the  direction. 
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Figure  4.b.  shows  a  detected  cyclone,  the  jetstream  and  surface  pressure  contours.  Again,  the 
lines  around  the  cyclone  core  are  the  wind  trajectories,  and  the  vertical  vorticities  are  mapped 
As  can  be  seen,  a  low  surface  pressure  center  is  perfectly  matched  with  the  detected  cyclone  in 
space. 


Figure  4a.  Two  Detected  Cyclones 


Figure  4b.  One  Detected  Cyclone  and  Surface  Pressure  Distribution. 


Future  Research:  Future  efforts  may  include  ocean  eddy  detection  firom  current  fields  by  using 
the  similar  techniques  for  cyclone  detection,  efficient  recognition  and  tracking  of  feature 
movement  along  time,  and  visualizing  features  systematically. 


^^e^nWere’ty**^*^'  ^  Robert  J.  Moorhead,  NFS  Engineering  Research  Center,  Mississippi 
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An  Object-Oriented  Prototype  for  a  Geophysical  Database 
Subtask:  Prototype  Implementation 


Chandrashekar  Ramanathan 
Julia  Hodges 
P.O.  Drawer  CS 
Mississippi  State.  MS  39762 
{shekar.hodges}(§>cs.  msstate.edu 


TITLE:  Prototype  Implementation  of  an  Object-Oriented  Geophysical  Database 

OBJIECnVE:  The  objective  is  to  develop  a  prototype  geophysical  database  by  using  a  commercial 
object-oriented  database  management  system  (OODBMS).  The  data  in  the  Naval  Environmental 
Operadtmal  Nowcasting  System  (NEONS)  relational  database  should  be  transformed  and  stored  in 
the  new  system  called  Objl^ONS.  It  is  envisaged  that  the  resulting  database  system  and  the  qrplica- 
tions  develqped  on  top  of  the  system  will  be  mme  “natural”  for  the  users  and  application  developers 
by  virtue  of  its  object-orientedness. 

APPROACH:  Develt^nnent  of  any  database  system  involves  at  least  three  things:  the  data,  a  data¬ 
base  schema  for  dre  data,  and  a  DBMS.  The  NEONS  database  system  served  as  a  source  of  data  for 
ObjNEONC.  The  database  schema  for  this  system  is  based  primarily  (hi  an  earlier  wcnic  involved 
in  providing  an  object-oriented  view  of  the  existing  NEONS  relational  database.  Noting  that  the 
objective  is  to  develop  an  object-oriented  database,  a  commercial  (X)DBMS  ObjectSttne  was  cho¬ 
sen  after  doing  a  feature  evaluation  of  the  the  various  available  systems. 

Re-engineering  an  existing  relational  database  system  such  as  NEONS  to  an  object-eriented 
versum  involves  mt^ing  the  relational  schema  into  an  object-(Hiented  ((X>)  schema.  The  OO 
schema  should  subsume  the  relational  schema  in  such  a  way  Aat  there  is  no  loss  of  infcnmation  ftom 
the  data.  NEONS  primarily  consists  of  four  types  of  data:  image  data,  grid  data,  line  data,  and  lit 
(lat-Jon-time)  data.  The  grid  data  type  was  chosen  as  the  starting  point  for  this  implementation. 
The  relational  schema  for  grid  data  was  transformed  into  an  (X)  schema.  This  schema  was  then 
transformed  into  ObjectStore  class  definitions.  These  object  classes  were  then  instantiated  using  the 
data  present  in  the  NEONS  database  by  yet  another  transftnmation  of  the  relational  tuples  into  ob¬ 
jects  and  relationships.  Figure  1  summarizes  the  whole  process. 

There  are  scnne  similarities  and  differences  between  the  current  work  and  the  earlier  work  of 
providing  an  object-oriented  view  of  NEONS.  Both  of  them  involve  schema  and  data  transforma- 
ti(His.  However,  in  the  current  system,  the  transformed  objects  are  persistent  in  the  database  that  is 
managed  by  an  OODBMS  whereas  in  the  earlier  system,  only  the  relational  data  was  persistent  and 
the  objects  were  transient  Another  point  to  note  is  that  in  the  current  system,  the  directions  of  the 
arrows  indicating  transformations  in  Hgure  1  are  uni-directionaL  That  is,  there  is  no  provision  for 
translating  the  objects  into  tuples  that  can  be  stored  in  the  relational  database.  ObjNEONS  may  con¬ 
tain  data  not  (Hily  ported  from  NEONS  but  also  those  that  are  newly  generated  by  the  scientists. 

As  mentioned  earlier,  the  current  w(Hk  focuses  on  the  grid  data.  A  partial  object-oriented 
schema  for  the  grid  data  is  shown  in  Figure  2.  The  notation  provided  by  the  FUSION  object-ori¬ 
ented  software  development  methcxl  is  used  in  the  object  class  diagram.  The  rectangular  boxes  rep¬ 
resent  object  classes  and  the  diamonds  represent  relationships. 
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ObjNEONS  Database  System 


NEONS  Database  System 


Figure  1. 

The  triangle  represents  the  generalization/specialization  relationship.  A  filled  triangle  indicates  ex¬ 
clusive  sub-classes  while  die  white  triangle  represents  inclusive  sub-classes. 

The  primary  goal  of  the  object-oriented  schema  development  was  to  exploit  all  the  features 
provided  by  the  object-oriented  model  to  provide  a  view  that  represents  the  real  w(»rld  as  much  as 
possible.  To  diat  extent,  the  design  of  grid  geometry  and  grid  levels  differ  substantially  (not  surpris¬ 
ingly)  from  the  corresponding  relational  schema.  In  the  relational  schema,  the  projection  informa- 
tirm  is  stored  along  with  the  registered  geometry  just  as  ordinary  numbers  and  their  interpretation 
(whether  they  represent  ‘minimum  latitude*  or  ‘row  interval’)  is  determined  from  the  descriptive 
realm  based  on  the  projection  type.  We  decided  to  make  this  explicit  in  the  schema  itself  by  enumer¬ 
ating  all  the  projections  as  subclasses  of  a  single  Projection  class  so  that  no  extra  indiiection  is  re¬ 
quired  to  know  more  about  the  data  (the  metadata).  It  is  stored  in  the  schema  itself.  This  ability  to 
capture  mote  data  semantics  is  one  of  the  biggest  strengths  of  the  object-oriented  data  modeL 

The  transformation  of  relational  tuples  in  NEONS  to  objects  in  ObjNEONS  merits  some  elab¬ 
oration.  The  transformation  is  not  trivial  in  tlw  sense  that  not  every  single  tuple  is  a  single  object. 
The  relational  model  stores  the  relationships  implicitly  in  the  form  of  foreign  keys  while  the  object 
model  represents  them  explicitly  in  the  form  pointers  or  sets  of  pointm^  to  the  related  object  class. 
Thmfore,  whenever  a  tuple  with  a  foreign  key  is  being  transformed  into  an  object,  a  pointer  to  the 
related  object  (specified  by  the  foreign  key)  must  be  fetched  and  assigned  as  part  of  the  object’s  defi¬ 
nition.  Objec^tore  supports  the  maintenance  of  relationships  by  automatically  updating  the  links 
in  one  direction  when  the  link  is  updated  in  the  other  direction.  ObjectStore  supports  one-to-one, 
one-to-many,  and  many-to-many  relationships. 

Another  important  feature  of  ObjNEONS  is  that  a  lot  of  the  metadata  (stored  in  the  descriptive 
reohn  in  the  case  of  NEONS)  is  stored  along  with  the  data  itself.  Fot  example,  it  was  observed  that 
NEONS  contains  a  lot  data  values  that  have  units  attached  to  them.  While  the  primary  realm  contains 
a  level  value,  say  13.5,  the  units  of  this  value,  say  “milli-bars,”  is  stored  in  the  descriptive  realm. 
It  should  be  noted  that  there  might  not  be  a  better  way  of  doing  this  in  the  relational  and  conventional 
programming  context  without  building  in  undesirable  redundancy.  To  facilitate  the  unification  of 
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the  data  value  and  the  units  of  measurement  (the  metadata),  a  new  concrete  object  class  called  Value 
was  defined.  Each  instance  of  the  Value  class  contains  a  pair  of  values,  namely,  the  numeric  value 
and  a  character  string  representing  the  units.  Also,  the  instances  of  Value  may  be  used  in  any  context 
where  a  numeric  value  is  applicable.  Value  can  also  be  made  optionally  ‘intelligent’  to  prevent  com¬ 
bining  incompatible  units  in  computations.  Value  instances  are  used  extensively  in  ObjNEONS  to 
represent  latitude,  longimde,  levels,  etc. 

The  approach  taken  for  mapping  the  OO  schema  into  implementation  data  structure  in  Object- 
Stfxre  is  as  follows.  In  general,  there  are  two  components  in  a  database:  the  extension  and  the  inten¬ 
sion.  The  extension  of  the  database  is  the  actual  data  (objects)  in  the  database.  The  intension  of  a 
database  “describes”  the  data  without  really  enumerating  the  actual  data.  The  schema  of  a  database 
is  a  true  representative  of  die  intension  of  Ae  database.  In  order  to  provide  access  to  the  extension 
of  the  ObjNEONS  database,  each  class  definition  is  augmented  by  an  additional  static  data  member 
called  extent,  which  is  a  set  (provided  by  ObjectStore)  of  pointers  to  all  persistent  instances  of  that 
class.  Any  class  can  be  queried  by  examining  the  exre/ir  of  each  class.  The  many-end  of  a  relation¬ 
ship  is  implemented  by  using  sets  of  pointers.  Hiese  sets  of  pointers  are  automatically  maintained 
by  the  DBMS.  This  type  of  implementation  is  very  convenient  for  providing  fast  responses  to  quer¬ 
ies  without  any  computational  overhead  (like  joins)  in  the  application  program.  For  example,  the 
object  class  CMdGeometry  contains  a  set  of  pointers  to  relat^  GridDataset  objects  so  that,  given 
a  particular  geometry,  all  the  corresponding  data  sets  can  be  retrieved  without  any  further  query. 

RESULTS:  The  schema  for  grid  data  was  translated  into  ObjectStore  C-h-  class  definitions.  Em¬ 
bedded  SQL  routines  were  written  to  read  the  data  from  the  NEONS  database  and  the  data  was  used 
to  build  new  objects  diat  were  consequently  stored  by  using  the  OODBMS.  New  utility  concrete 
class  definititHts  were  written  and  used  (e.g.,  stxings,  date,  time,  epochal  time,  ‘smart*  vdues,  etc.) 
fix’ application  development  convenience.  The  implementation  of  the  transformation  of  the  NEONS 
data  into  ObjNEONS  data  is  being  carried  out  in  phases.  Currently,  all  the  associative  and  descrip¬ 
tive  data  of  NEONS  has  been  stored  in  ObjNEONS.  Work  is  in  progress  to  store  the  data  from  the 
primary  realm. 

FUTURE  RESEARCH:  Future  research  should  concentrate  on  developing  a  full-fledged  imple¬ 
mentation  of  ObjNEONS  that  should  not  only  include  other  NEONS  data  types  (viz.,  image,  Une, 
and  lit)  but  also  some  newer  types  like  the  volumetric  data  type.  Object-oriented  technology  offers 
immense  potential.  Efforts  should  be  carried  out  to  tap  that  potential  to  the  maximum  extent  in  sever¬ 
al  areas  of  software  development  Sridhar  Koduri  is  working  on  another  project  to  develop  a  user 
interface  fix  the  grid  data  stored  in  ObjNEONS  object-oriented  database.  The  analysis  and  design 
of  die  interface  will  involve  consultation  with  the  scientists  at  CAST  to  ensure  that  the  resulting  in¬ 
terface  will  provide  an  easy-to-use  environment  for  grid  data. 

Some  new  work  could  be  done  to  study  the  suitability  and  applicability  of  ObjectStore’s  ver¬ 
sion  handling  capability.  Version  management  allows  multiple  versions  of  the  same  object  to  be 
stored  in  the  database.  This  will  help  the  data  toevolve  naturally  while  hiding  the  intermediate  object 
states  fipom  other  transactions. 

RESEARCH  ADVISOR:  Dr.  Julia  Hodges,  MSU  Department  of  Computer  Science 
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Rgure2.  Object  Schema  for  Grid  Data 
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An  Object-Oriented  Prototype  for  a  Geophysical  Database 
Subtask:  An  Object-Oriented  Database  Schema  for  Image  Data 

Koduri  Sridhar 
Julia  Hodges 
P.O.  Drawer  CS 
Mississippi  State,  MS  39762 
{ sri  j)odges}@cs.msstate.edu 

Project  Title:  Object-Oriented  Database  Schema  for  Image  data 

Objective:  The  objective  is  to  develop  an  object-oriented  schema  for  the  image  data  type  in 
NEONS. 

Approach:  The  database  schema  for  the  object  classes  and  relationships  needed  to  represent  image 
data  was  (feveloped  using  the  Fusion  object-oriented  software  development  methodology.  Fusion 
divides  the  develc^ment  process  into  analysis,  design,  and  implementation[Coleman  et  al.  1994]. 
In  the  analysis  phase,  die  developer  defines  the  intended  behavior  of  the  systeno.  The  concepts  that 
exist  in  the  domain  of  the  problem  and  die  reladonships  between  them  are  captured  in  the  object 
model  in  this  phase.  In  the  design  phase,  the  developer  chooses  how  the  system  (^leradcHis  are  to 
be  inqilemented  by  the  run-time  behavior  of  interacting  objects.  During  this  phase  operations  are 
attached  to  classes;  the  developer  also  chooses  how  objects  refer  to  each  other  and  what  the  apprc^- 
ate  inheritance  relationships  are  between  classes.  The  substructures  of  all  the  classes  and  their  opera- 
ti(Mis  are  investigated  in  detail[Goleman  et  al.  1994].  During  the  implementation  phase,  the  develop¬ 
er  toms  the  deagn  into  code  in  a  particular  programming  language  and  DBMS;  in  our  case;  this  is 
C-M-  and  ObjectStoie.  The  notation  of  Fusion  allows  the  systematic  discovery  and  preservation  of 
the  object  structure  of  the  system. 

The  analysis  and  design  of  the  object-oriented  schema  for  image  data  involved  consultation 
with  the  scientists  at  CAST  to  ensure  that  the  resulting  database  wiU  provide  a  more  natural  represen- 
taticHi  of  die  data.  The  analysis  phase  and  part  of  die  design  phase  of  the  project  are  complete  at  this 
poinL  In  die  analysis  phase  classes  of  objects  in  the  database  system  were  identified.  Special  care 
was  taken  in  identifying  the  conceptual  objects  as  well  as  the  real  objects.  The  real  world  associa¬ 
tions  that  exist  or  conceptual  relationships  between  these  different  classes  were  identified.  The 
stronger  associations  were  converted  to  aggregations.  Based  on  the  semantics  of  the  data,  the  partici- 
patitm  and  cardinality  of  the  classes  in  the  associations  were  determined.  A  cardinality  constraint 
restricts  die  number  of  objects  which  may  be  associated  with  each  other  in  arelationship.  All  objects 
in  the  adjacent  class  must  appear  in  the  relationship;  this  is  indicated  by  a  total  marker. 

We  had  a  meeting  with  our  CAST  contact  person,  Mr.  Valentine,  to  review  the  design  and  the 
semantics  of  the  data  in  the  database  schema.  He  provided  input  on  the  details  of  the  image  data  and 
the  refined  system  requiranents.  Based  on  our  discussions  in  the  meeting  and  the  database  design 
document  fOT  NEONS,  we  developed  the  object  model  for  the  image  data  in  a  refining  process  using 
Fusion  notation  and  methodology. 

The  object  model  notation  of  Fusion  is  based  on  an  extended  entity  relationship  notation.  It 
can  represent  classes,  attributes,  relationships,  aggregation,  generalization,  cardinality,  and  partici- 
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pati(m[Coleiiiaii  et  al.  1994].  The  boxes  are  the  classes  and  the  diamonds  are  the  relationships.  Each 
vlass  is  represented  by  a  box,  with  the  name  of  the  class  at  the  top,  separated  from  the  rest  of  the  box 
by  a  line.  The  names  of  the  attributes  belonging  to  the  class  are  named  below  the  line  and  are  enclosed 
in  the  box  of  each  class.  The  relationships  are  shown  as  a  diamond  joined  to  the  participating  classes 
by  arcs.  The  aggregaticm  (the  class  which  has  component  classes)  is  represented  by  nested  boxes. 
The  notation  for  a  generalization  (is-a  or  a-4dnd~of  relationship)  is  a  filled  triangle  connecting  a 
supertype  to  subtypes.  The  cardinalities  (1  -one,'!-- one  or  more,* -zero  OTnoore)  are  represented 
by  annotating  the  arcs  connecting  the  relationship  to  the  classes.  Small  square  filled  boxes  represent 
total  participation  of  the  class  in  the  relationship. 

Results:  The  object  model  which  defines  the  static  structure  of  the  information  in  the  image  data¬ 
base  schema  (shown  in  figure  1)  was  designed  and  developed. 


Figure  1.  Object  Model  for  Image  data 
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Future  Rcseardi:  We  plan  to  implement  prototype  object-oriented  datal»se  fw  the  image  data  us¬ 
ing  ObjectStore  -  a  premier  object-oriented  database  management  system. 

Reference:  Coleman,  Derek.,  et  aL  1994.  Object-Oriented  Development  -  The  Fusion  Method, 
Prentice  Hall,  Englewood  Qiffs,  New  Jersey  OntTl. 

Research  Advisor:  Dr.  Julia  Hodges,  MSU  Department  of  Cmnpoter  Science 

***41111* 
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An  Object-Orirated  Prototype  for  a  Geophysical  Database 
Subtask:  Evaluation  of  Commercial  Object-Oriented  DBMSs 

Chandrashekar  Ramanathan 
Koduri  Sridhar 
Julia  Hodges 
P.O.  Drawer  CS 
Mississippi  State,  MS  39762 
( shekar,srUtod^  }@cs.msstate.edu 


PROJECT  TITLE:  Evaluation  of  Commercial  Object-Oriented  Database  Management  Systems 
(ODBMS) 

OBJECTIVE:  To  evaluate  cranmercially  available  OODBMSs  and  recommend  for  purchase  sys¬ 
tems  that  appear  to  best  fit  CAST’s  database  needs. 

APPROACH:  Selecting  an  ODBMS  ftH*  purchase  is  a  cranplex  task.  We  gave  careful  consider¬ 
ation  to  several  aspects  before  arriving  at  a  decision.  For  our  study,  we  considered  nine  popular 
ODBMS  products,  namely,  GEMSTONE,  Mj\.T.I.S.S.E,  MONTAGE,  OBJECTSTORE,  ON- 
TOS,  OBJECnVlTY/DB,  POET,  UniSQL,  and  VERS  ANT.  A  major  factor  in  choosing  these  nine 
products  for  evaluafitm  was  that  all  of  them  were  C-h-  compatible,  which  was  rated  as  the  most  im¬ 
portant  requirement  by  CAST.  We  also  ensured  that  the  products  that  we  considered  would  run  on 
the  platform  specified  by  CAST  (a  SUN  Sparc  running  under  Solaris). 

The  main  features  of  interest  in  any  ODBMS  are  the  primitive  data  types  and  the  built-4n  ag¬ 
gregates;  support  for  composite/amiplex  objects,  dynamic  schema  evolution,  version  management, 
Itxig  transacticMi  management,  lock  management,  and  audiorization;  and  the  intorface  tools.  We  pre¬ 
pared  a  list  of  desirable  and  required  features  that  the  ODBMS  for  CAST  should  support  and  asked 
the  vendors  to  tell  us  whether  their  system  supported  them  or  not  This  was  done  by  preparing  a 
questiramaire  and  sending  it  to  the  vendors.  The  questionnaire  is  attached  at  the  end  of  this  report 
The  respcmses  from  the  vendors,  the  information  from  computer  science  literature,  literature  pro¬ 
vided  by  the  vendors,  and  some  published  reviews  of  the  products  were  combined  to  get  a  consoli¬ 
dated  picture  of  all  the  systems  under  review.  These  results,  compiled  in  the  form  of  an  information 
grid,  are  attached  at  the  end  of  this  report  Following  is  a  brief  description  of  the  various  systems 
under  consideration. 

Different  products  support  different  machines  and  operating  systems.  GEMSTONE  is  a  prod¬ 
uct  of  Servio  Corporation.  The  system  is  well-suited  for  use  in  multi-user,  multi-platform  client/ 
server  applications.  M.A.T.I.S.S.E.  is  a  heterogeneous  cross  platform  client/server  architecture- 
based  ODBMS  developed  by  ADB,  Inc.  MONTAGE  is  the  commercial  version  of  the  well-known 
Postgres  DBMS  (first  developed  at  the  University  of  California  at  Berkeley)  and  is  produced  by 
Montage  Software,  Inc.  MONTAGE  is  a  fully  relatitmal  database  management  system  having  ex- 
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tensions  to  support  object-oriented  concepts  and  models.  OBJECTSTORE,  from  Object  Design, 
Inc.,  is  an  ODBMS  that  provides  a  tightly  integrated  object-oriented  progranuning  interface  using 
C-f-t-.  It  has  a  client/server  architecture  where  each  woiicstation  can  simultaneously  access  multiple 
databases  at  many  servers.  A  product  of  Objectivity,  Inc.,  OBJECl  lV ITY/DB  has  a  fully  distrib¬ 
uted  client/server  architecture  that  transparently  manages  objects  across  heterogeneous  environ¬ 
ments  and  multiple  databases.  ONTOS,  a  multi-client,  multi-server  distributed  database  manage¬ 
ment  system,  is  a  product  of  Ontologic,  Inc.  POET  (Persistent  Objects  and  Extended  database 
Tbchnology)  is  a  product  of  BKS  Software  that  has  a  tight  semantic  integration  with  0+4-.  UniSQL 
is  a  unified  relational  andobject-tviented  database  system  produced  by  UniSQL,  Inc.  Finally,  VER- 
SANT  is  a  clien^server  OODBMS  that  is  compatible  for  distributed,  multi-user  applications. 

We  had  requested  our  CAST  contact  person,  Mr.  Ramesh  Krishnamagaru,  to  send  us  some 
input  on  the  system  requirements  and  preferences  on  a  scale  of  0  (not  important)  to  4  (most  impor¬ 
tant)  on  various  features  of  ODBMS.  Our  evaluation  of  the  nine  products  was  based  on  the  impor¬ 
tance  assigned  to  the  features  vis-a-vis  the  products  support  for  the  several  important  features  (e.g., 
price,  language  supptnt,  interface,  technical  aspects,  etc.). 

RESULTS:  The  systems  we  evaluated  can  be  broadly  classified  into  two  categories:  those  that  are 
built  by  extending  C++  to  handle  persistent  objects  and  those  that  are  built  by  extending  the  relation¬ 
al  model  to  handle  hierarchies  of  objects.  OBJECTSTORE,  VERSANT,  POET,  OB  JElti  1 V ITY/ 
DB,  ONTOS,  and  M.A.T.I.S.S.E.  come  under  the  former  category.  UniSQL  and  MONTAGE  come 
under  the  category  of  extended  relational  databases.  GEMSTONE  is  neither  an  extended  C++  nor 
an  extended  relational  system.  It  is  recognized  as  the  most  nearly  pure  object-oriented  DBMS  and 
is  one  of  the  oldest  commercial  ODBMS  products.  Based  on  our  evaluation,  we  felt  that  CASTs 
needs  can  best  be  met  by  one  of  these  three  products  (in  decreasing  order  of  preference):  OBJECT- 
STORE,  UniSQL,  and  GEMSTONE.  Following  is  a  brief  critique  of  all  the  systems  based  on  the 
criteria  we  had  set  that  led  to  our  final  recommendations. 

Among  the  extended  relational  database  systems,  we  found  that  MONTAGE  does  not  allow 
methods  for  the  classes  to  be  written  in  C++  (although  it  allows  C++  applications  to  access  the  data¬ 
base),  a  factor  that  eliminated  it  from  consideration.  On  the  other  hand,  methods  in  UniSQL  can 
be  written  in  any  compiled  language.  Looking  at  the  information  grid,  it  can  be  seen  that  UniSQL 
meets  all  our  evaluation  requirements  fairly  well.  Also,  it  comes  with  an  extended  SQL  language, 
which  might  help  all  the  current  users  of  relational  databases  at  CAST  to  get  started  quickly  on  using 
the  system.  However,  it  should  be  noted  that  the  ease  and  naturalness  with  which  C++  applications 
could  be  developed  will  be  known  only  after  actually  working  with  the  system.  This  is  a  point  of 
concern  with  UniSQL  because  it  was  not  developed  by  extending  an  object-oriented  programming 
language.  Also,  it  is  not  clear  how  well  UniSQL  maintains  referential  integrity  because,  for  exam¬ 
ple,  it  cannot  handle  exclusive  components  of  composite  objects. 

We  recommended  GEMSTONE  because  GEMSTONE  is  developed  based  on  the  Smalltalk 
language’s  programming  model,  which  is  considered  to  be  one  of  the  ‘pure’  object-oriented  lan- 
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guages.  Therefore,  we  think  that  the  full  benefits  of  object-orientation  can  be  realized  by  using  such 
a  system.  Note  that  the  system  itself  is  language  independent  in  the  sense  that  it  doesn’t  matter 
whether  objects  are  created  by  applications  written  in  Smalltalk  or  C-H-,  Once  again,  it  is  not  clear 
how  easy  it  is  to  make  C++  appUcadu-s  communicate  with  Smalltalk  environment  One  individual 
who  is  currently  involved  in  trying  to  do  this  has  told  us  that  it  appears  to  be  awkward,  requiring 
a  lot  of  preliminary  bookkeeping. 

We  think  that  the  ability  to  maintain  multiple  versions  of  conceptually  the  same  object  (version 
management)  should  prove  to  be  useful  in  the  long  term  for  CAST  applications.  In  fact,  we  intend 
to  explore  how  versions  can  be  useful  in  the  prototype  for  geophysical  databases  we  are  building. 
TherefOTe,  based  on  the  ability  of  the  systems  to  support  versions,  we  have  excluded  ONTOS  and 
POET,  both  of  which  support  neither  object  versions  nm:  schema  versions.  Among  the  products, 
POET  and  VERS  ANT  provide  poOT  database  authorization  control.  Also,  VERS  ANT  relies  on  the 
operating  system  for  disk  media  protection.  From  the  available  information,  POET  does  not  have 
any  ntm-^nogrammatic  interface.  Despite  our  repeated  requests  for  information  from  the  vendor 
about  OBJECnvrrY/DB,  we  did  not  have  enough  information  for  comparison  at  the  time  of  doing 
the  evaluation.  M.A.T.I.S.S£.  has  some  limitations  comparatively  in  the  areas  of  transaction  pro¬ 
cessing  and  also  in  the  provision  of  built-in  aggregates.  We  decided  to  include  OBJECH'STORE 
as  one  of  the  choices  because  of  its  neat  and  tight  integration  with  C++  and  our  observation  that  OB- 
JECTSTORE  is  one  of  the  most  pt^ular  and  widely  known  products  in  the  area.  One  of  its  strengths 
is  to  treat  ^pe  independent  of  persistence.  That  is,  any  conceivable  C++  object  can  be  made  persis¬ 
tent  with  little  change  to  the  corresponding  transient  object’s  definition.  It  also  meets  most  our  eval¬ 
uation  criteria  fairly  well  The  OBJECTTSTORE  vendor  provided  us  with  the  name  of  a  user  who 
had  implemented  an  image  database  using  OB  JECTSTORE.  The  information  that  we  got  form  this 
user  iiKlicated  a  high  degree  of  satisfaction  with  the  product.  In  general,  OBJECJTSTORE  should 
meet  all  the  requirements  very  well. 

After  we  completed  our  evaluation  and  submitted  our  recommendation  to  CAST,  they  pur¬ 
chased  a  copy  of  OBJECTSTORE.  It  has  been  installed  in  one  of  the  research  laboratories  in  the 
Department  of  Cbmputer  Science  at  Mississippi  State  University. 

FUTURE  RESEARCH:  An  object-oriented  database  for  the  grid  data  by  using  the  OBJECT- 
STORE  system  is  already  under  development  by  Chandrashekar  Ramanathan.  We  also  plan  to  store 
in  the  object-oriented  database  other  data  types  such  as  the  image  dat.,  the  lit  data,  and  the  line  data 
currently  in  the  NEONS  relational  database. 

RESEARCH  ADVISOR:  Dr.  Julia  Hodges,  MSU  Department  of  Computer  Science 
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Questtoimaire  on  ODBMS  for  Vendors 

1.  Which  of  the  following  platforms  does  your  oodbms  support? 

Sun  SPARC  running  UNDC/SOLARIS  2 
Sun  SPARC  running  SunOS  4.1 

n.  Please  provide  the  following  informaticm  amceming  costs. 

1.  What  is  die  cost  of  purchasing  your  system? 

2.  Do  you  offer  an  education  discount?  If  so,  please  briefly  describe  the 
terms  and  the  amount  of  the  discount 

3.  Please  briefly  describe  the  cost  and  terms  of  the  technical  support  that  you 
provide  fcv  your  oodbms. 

4.  What  provision  do  you  have  feu*  upgrades? 


nL  Please  made  with  an  X  those  features  that  are  supported  by  your  system. 

1.  Primitive  data  types 

real 

integer 

string 

character 

binary  objects 

images 

othera  (please  specify) 

2.  Aggregates 

sets 

bags 

lists 

arrays 

3.  Ccunplex  objects 

exclusive  components 
shared  components 

4.  Automatic  referential  integrity  (relationships  supported) 

1:1 

l:many 

manynnany 

5.  Versions 

support  for  object  versions 
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support  for  automatically  metging  object  versions 
schema  versions 


6.  Interactive  tools  available  for 

cieationA^hange  of  schema 
instantiating  objects 
DBA  operations 

7.  Schema  evoluticm 

add  a  new  attribute  to  a  class 
drop  an  attribute 
change  name  of  a  method 
change  code  of  a  method 

8.  lYansacticHi  prcqterties 

long  transaction  (hours,  weeks,  months,  etc.) 
shared  transactions 

9.  Granularity  of  locks 

data  page 
index  page 

a  single  class  within  a  page 
a  single  instance  within  a  page 
composite  object 

10.  Authorizatitm  control 

database  level 
class  level 

attribute  oc  data  member  level 

11.  Disk  media  protection 

dual  co^y  disk  mirroiing 
deferred  copy 

12.  Backup/Recovery 

tools  to  backup  database 

13.  Distributed  databases 

14.  Did  anybody  develop  a  geophysical  application  with  the  system? 

15.  Any  other  additional  infcnmation 

16.  C-H- compiler  cmnpatibility 

cfixxit2.1 
cfrcHit  3.0 
gcc  2.4.5 
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ODBMS  Information  Grid 
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Holiie  Molyneux 

M.S.  Program,  Department  of  Mathematics 
University  of  Southern  Mississippi 

Title:  Test  and  Evaluation  of  the  CAST  Model  Evaluation  System  (CMES) 

Objective:  The  objectives  were  to  gain  an  understanding  of  the  operation  and  capabilities  of  the 
CNffiS,  and  using  designated  oceanographic  data  sets,  evaluate  the  utility  and  friendliness  of  the 
graphit^  user  interface,  and  the  utility  of  the  CMES  as  a  tool  for  ocean  model  development. 

Approach:  The  initial  effort  was  in  learning  how  to  select  data  and  use  the  visuali2ation  mode 
(VISMOD)  by  experimenting  with  the  various  data  sets  already  residing  in  the  CMES  database. 
Following  this,  bathymetry  and  water  quality  data  sets  from  the  Back  Bay  of  Biloxi  were  read 
into  files  and  formatted  for  ingestion  into  the  CMES.  It  was  necessary  to  remove  extraneous 
symbols,  and  to  develop  programs  to  write  the  data  into  columns  and  convert  minutes  and 
seconds  of  latitude  and  longitude  into  degrees.  Once  formatted,  the  data  sets  were  ingestcxl.  The 
CMES  was  dien  used  to  interpolate  the  data  to  a  grid  and  exportZ/display  the  results.  The  other 
approach  was  to  run  DieCAST  model  to  simulate  a  30-day  period  in  the  Gulf  of  Mexico  at 
20  levels.  Since  the  grid  was  already  in  the  databases,  model  output  could  be  imported  directly 
into  the  CMES  and  ^d  not  have  to  be  ingested.  A  program  developed  by  Dr.  Harsh  Anand  of 
CAST  was  modified  to  accommodate  a  30-day  period  with  20  levels.  The  resulting  file  was 
imported  into  die  CMES  and  the  data  displayed. 

Results:  VISMOD  was  found  to  be  very  self-explanatory  and  user-friendly.  The  broad  range  of 
options  allowed  the  data  to  be  displayed  in  a  form  well  suited  to  the  parameter  of  interest.  For 
example,  when  the  change  in  a  parameter  was  very  gradual,  it  was  somewhat  difficult  to  see  the 
color  distinctions  using  the  topographic  hues.  However,  switching  to  rainbow  tones  made  the 
distinction  clear.  In  the  case  of  2-D  graphics,  changing  the  date  or  level  to  be  viewed  was  a 
simple  procedure  done  direcUy  within  VISMOD.  The  ability  to  overlay  grids  and  coastlines 
were  also  useful.  Interpolations  and  the  import  tool  were  straightforward,  but  could  benefit  from 
the  inclusion  of  help  screens  or  a  user’s  manual.  For  example,  depths  must  be  specified  for 
interpolations.  It  is  possible  to  choose  standard  depths,  user-specified  depths,  or  user  depths 
from  a  file.  However,  it  was  not  clear  what  the  standard  depths  were,  or  what  format  would  be 
required.  When  interpolation  was  completed,  saving  the  results  for  display  as  gridded  data  and 
expOTting  it  to  a  file  required  only  clicking  on  the  save  or  export  buttons  and  specifying  a 
filename,  making  these  features  very  convenient.  Overall,  the  CMES  proved  to  be  an  excellent 
tool  for  visualization  of  the  designated  oceanographic  data  sets.  With  simple  format  changes,  it 
easily  accepted  interpolated  and  displayed  the  data.  The  DieCAST  model  also  ran  successfully 
on  the  CMES.  Formatting  the  output  for  importation  required  modification  of  an  existing 
program.  The  model’s  output  was  successfully  imported  into  the  CMES  and  the  results 
displayed.  Figures  1  and  2  show  pressure  and  temperature,  respectively,  on  day  30  at  the  top 
level.  It  would  be  advantageous  to  be  able  to  setup,  execute,  analyze  DieCAST  runs  directly 
from  the  CMES,  without  5te  necessity  of  intermediate  programming  steps.  The  modified 
program  could  serve  as  the  basis  of  such  a  CMES  addition. 

Future  Research:  For  the  CMES  to  be  useful  and  accessible,  help  screens  and  a  user’s  manual 
describing  all  options  should  be  prepared.  To  make  the  CMES  more  convenient  and  self- 
contained,  modifications  should  be  made  which  would  allow  models  to  be  setup,  executed,  and 
analyzed  directly. 

Research  Advisor:  Dr.  Louise  Perkins,  Department  of  Scientific  Computing,  University  of 
Southern  Mississippi. 
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Figure  1.  DieCAST  Model  Output  of  Temperature  on  Day  30. 


OOOOOOOOC>OQO^^OO^ 

Aooooooopqpqqqqq  ■ 
^  M  ^  A  ^  ^  A  A  A  A  A  A  A  * 


04  ^  ^ 


^  C=  81 

I  I  I 


D 


30 


Figure  2.  DieCAST  Model  Output  of  Pressure  (105  dyncs/crrf)  on  Day  30. 


Mickey  L.  Barton 

B.S.  Program,  College  of  Science  and  Technology 
University  of  Southern  Mississippi 

Project  #1  Title:  Enhancement  of  the  Naval  Interactive  Data  Analysis  System  (NIDAS)  In 
Viewing  Multiple  Fronts  and  Eddies 

Objective:  The  analysis  of  fronts  and  eddies  includes  a  comparison  of  their  changes  over  time. 
It  is  easier  to  make  these  comparisons  when  the  fronts  or  eddies  are  viewed  simultaneously.  The 
objective  of  this  project  was  to  give  the  user  the  ability  to  view  multiple  front  or  eddy  data  in  one 
plot  using  NIDAS.  The  user  was  to  be  given  the  ability  to  select  one,  multiple,  or  all  data  from 
the  pick  Ust,  as  well  as  to  display  this  data  in  separate  colors  when  needed. 

Approach:  The  interaction  of  the  NIDAS  functions  related  to  the  selection  and  display  of  data 
was  first  studied.  The  approach  was  to  see  how  the  selection  processes  were  implemented,  then 
see  how  to  implement  the  selection  of  multiple  fronts/eddies  and  colors. 

Results:  The  OSF/MOTIF  widgets  associated  with  the  selection  of  fronts  and  eddies  were 
modified,  as  were  widgets  associated  with  the  selection  of  color.  NIDAS  now  gives  the  user  the 
ability  to  display  one,  multiple,  or  all  fronts  or  eddies.  The  user  also  has  the  ability  to  display 
fronts  and  eddies  in  multiple  colors  when  he/she  selects  up  to  seven  fronts  or  eddies.  If  the  user 
selects  more  than  seven  fronts  and  eddies,  they  are  displayed  in  one  color  only. 

Research  Advisor:  Mr.  Dharmesh  Kiishnamagaru,  Center  for  Air  Sea  Technology,  Mississippi 
State  University. 

********ii**********m***it*iiim************************** 

Project  #2  Title:  Investigation  of  a  Window  Environment  for  Retrieving  and/or  Viewing 
Oceanographic  Data  Over  the  Internet 

Objective:  Large  amounts  of  data  are  being  collected  over  the  worlds  bodies  of  waters. 
Scientists  need  to  be  able  to  access  this  data  for  use  with  their  models  and  other  projects.  One 
way  is  for  them  to  access  the  data  via  the  Internet  They  also  need  the  capability  to  view  the  data 
before  retrieving  it  so  as  not  to  waste  time  downloading  that  which  is  not  suitable  for  their 
project 

Approach:  The  GMT  plotting  system  (a  freeware  product)  was  first  investigated  to  determine 
its  applicability  for  use  as  a  plotting  tool.  A  vehicle  was  also  needed  to  allow  access  to  retrieve 
and/or  view  the  data  in  the  database.  Mosaic  was  studied  for  its  use  as  this  Internet  vehicle. 

Results:  The  GMT  plotting  system  was  found  to  be  adequate  as  the  system  plotting  tool.  We 
determined  that  Mosaic  was  an  excellent  way  to  allow  the  user  access  to  the  data  and  to  plot  it,  if 
so  desired.  Once  a  user  is  connected  he  may  connect  to  our  Mosaic  server.  Upon  selecting  the 
plot  ordering  form  the  user  has  access  to  ordering  the  data.  Once  the  user  has  entered  the 
attributes  requested,  he  may  then  view  and/or  retrieve  data. 

Research  Advisor:  Mr.  Valentine  Anantharaj,  Center  for  Air  Sea  Technology,  Mississippi  State 
University. 
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Owen  Lagarde 

M.C^  Program,  Department  of  Computer  Science 
Mississippi  State  University 

Title:  Exportation  and  Extraction  Capability  for  Remote  Users  of  a  Navy  Environmental  Operational 
Nowcasting  System  (NEONS)  Database 

Objective:  Initial  objectives  were  defined  by  requirements  of  the  Tactical  Oceanography  Wide  Area 
Network  (TOW  AN);  volumetric  data  sets  stor^  on  the  TOW  AN  system  must  be  accessible  and 
retrievable  to  a  remote  user's  file  system  via  a  connecting  network  (presumed  Internet).  This  capability 
could  be  achieved  through  two  independent  methods  —  a  command  line  interface  and  a  graphic^ 
interface  (as  an  extension  of  the  CAST  BROWSER,  an  existing  NEONS  database  access  tool). 

Secondary  requirements  included  the  following: 

The  command  line  interface  was  to  use  standard  input  and  output  streams,  allowing 
semiautonomous  batch  processing. 

The  graphical  interface  was  to  as  intuitive,  data  independent  and  code-modular  as  possible, 
allowing  easy  incorporation  of  data  types  other  than  volumetric. 

The  selection  scheme  was  to  allow  retrieval  of  contiguous  subsets  of  a  model  field  ranging  in  size 
from  one  data  sample  point  to  all  points  in  the  specified  field. 

Output  was  to  be  written  to  the  local  file  system,  either  as  space-  and  linefeed-delimited  ASCII 
text,  or  as  NCSA  Hierarchical  Data  Format  objects  (NCSA  HDF  3.3r3)  in  which  the  field  data 
would  be  considered  as  a  three  dimensional  block  of  values  and  stored  as  a  series  of  profiles;  three 
profiles  would  be  used  to  store  spatial  attributes  of  the  field  from  which  parameter  data  was 
extracted,  and  one  additional  profile  (for  each  extracted  field  parameter)  would  be  used  to  store 
parameter  data  values. 

Approach:  The  project  commenced  with  a  study  of  X-Motif  programming,  EMPRESS  imbedded 
SQL  opmtions,  CAST  BROWSER  design  and  mechanics,  and  NEONS  design  and  support  software 
mechanics.  A  command-line  version  was  developed  in  FORTRAN  and  C  using  NEONS  function 
calls.  Routines  for  non-interactive  retrieval  of  array  data  from  within  the  BROWSER  package  were 
designed  and  implemented  such  that  a  user  interface  allowing  selections  of  array  data  subsets  could  be 
add^  with  a  single  source  code  call.  The  BROWSER  package,  with  its  new  ability  to  retrieve  full 
arrays  from  an  EMPRESS-managed  NEONS  database,  was  then  used  to  verify  the  retrieval  output 
against  console  output  firom  an  EMPRESS  command  line  interface.  Verification  was  followed  by 
tentative  validation  of  output  formats  and  design  of  a  user  interface  for  select:  jn  of  array  data  subsets. 
The  user  interface  was  gradually  modified  to  include  the  following  user  options  and  abilities: 

Point  Selection  Area  --  users  would  be  presented  with  a  graphic  window  in  which  selections  could 
be  made  with  a  graphic  pointer  device  (presumed  a  mouse  or  lightpen);  the  array  would  be 
considered  as  evenly  filling  the  window  and  the  user  would  be  able  to  "click-and-drag"  the  pointer 
within  the  window  to  select  horizontal  subsets  of  the  array. 

Level  Selection  Area  —  users  would  be  presented  with  a  list  of  level  numbers  and  values  and  be 
able  to  "click-and-drag"  the  pointer  within  the  list  to  select  vertical  subsets  of  the  array. 
Latitude/longitude  Grid  Display  —  users  would  be  able  to  enable  or  disable  display  of  a  horizontal 
grid  that  would  denote  the  horizontal  boundaries  of  the  selected  array  and  label  intermittent  points 
of  latitude  and  longitude  along  the  array's  major  axes. 

-  Point  Display  -  users  would  be  able  to  enable  or  disable  display  of  a  highlighted  pixel  at  the 
relative  latitude-longitude  location  of  array  data  points  in  the  selection  window. 

Coastline  Display  —  users  would  be  able  to  enable  or  disable  display  of  coastlines  in  the  selection 
window  that  lay  within  the  area  of  the  selected  array. 

Point  Selection  Modes  -  users  would  be  able  to  choose  from  a  series  of  modes  which,  in  turn, 
would  alter  the  manner  in  which  the  user's  selection  action  was  interpreted.  Three  modes  were 
requested  by  the  clients:  "Area"  -  the  pointer  (via  a  "click-and-drag")  would  define  a  rectangle 
over  the  array’s  horizontal  surface  and  select  all  points  within  that  rectangle.  "Point"  —  the  pointer 
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would  define  a  location  in  the  array  and  the  single  array  data  point  closest  to  that  location  would  be 
selected.  "Great  Circle  Track"  (also  known  as  "Great  Circle  Path")  -  the  pointer  would  define  two 
locations  over  the  array's  horizontal  surface  to  be  used  as  the  control  points  of  a  curve  (Great 
Circle  Path  (GCP)  definition,  as  per  Navy  standards).  Array  data  points  closest  to  the  curve  of  the 
GCP  would  be  selected  (per  Naval  Research  Laboratory  GCP  volumetric  array  data  selection 
standard). 

Keyboard  Entry  of  Array  Boundaries  -  via  text  input  cells,  the  user  would  be  able  to  enter  the 
latitude  and  longitude  of  the  current  pointer  location  (and  pointer  starting  position,  if  required)  via 
the  keyboard,  as  an  alternative  to  manually  positioning  the  pointer  and  dragging  to  define  the  area. 
Typed  numerical  input  would  be  accurate  to  six  decimal  places  and,  since  the  values  would  be 
interpreted  as  point  locations,  they  would  be  independent  of  field  orientation,  the  coordinate 
system,  range,  location,  or  entry  order.  Upon  receiving  input  location  values,  the  interface  would 
update  the  ^splay  as  defined  by  the  currently  enabled  display  options. 

Results;  The  prototype  was  designed  and  installed  in  the  BROWSER  and  activated  by  a  menu  button 
in  the  volumetric  support  area.  A  user,  having  selected  a  specific  volumetric  array  with  the  current 
BROWSER  capabilities,  can  then  select  a  "Retrieve"  button  from  the  "Options"  menu  and  launch  a 
selection  tool  as  describe  above.  To  retrieve  array  data  from  the  database,  the  user  1)  chooses  a  point 
selection  mode  from  the  "Mode"  menu  bar  item  (default  "Area"),  2)  specifies  the  boundaries  of  the 
subsection  of  the  array  (either  by  "click-and-drag"  in  the  Map  Display  Window,  or  by  entering  the 
latitude  and  longitude  of  the  boundary  coordinates  into  keyboard  ent^  textboxes),  and  3)  specifies  the 
level  (vertical)  boundaries  of  the  array  in  the  Level  Selection  Area  (by  "click-and-drag"  within  the  list 
of  levels).  If  users  wish  a  mote  exact  specification  of  the  boundaries  of  usable  data  or  the  locations  of 
specific  data  points,  they  may  select  the  "Options"  menu  bar  item  and  toggle  the  grid,  coastlines,  and 
point  display  controls  as  desii^. 

After  verifying  output  of  the  data  retrieval/extraction  code,  object  code  modules  of  the  BROWSER 
were  re-linked  with  the  CAST  NetNeons  library  to  allow  the  BROWSER  to  access  NEONS  databases 
via  a  CIAST-developed  network  server  which  supports  remote  access  from  client  sites. 

In  general,  the  BROWSER  system  may  be  configured  as  follows: 

A  "provider"  of  a  NEONS  database  can  launch  un  instance  (child  process)  of  the  NetNeons  server 
using  a  port  on  their  host  machine.  The  server  inherits  the  access  privileges  of  the  user’s  account. 
The  “provider”  may  also  post  (via  electronic  mail  or  other  means)  the  location  of  the  server 
(Internet  address  of  the  host  machine  and  port  number  used  by  the  server)  and  general  information 
about  data  available  via  the  server. 

Prospective  clients  can  access  the  server  port  and  launch  an  instance  of  the  BROWSER  (compiled 
with  the  NetNEONS  client  library). 

Interaction  between  the  client's  instance  of  the  BROWSER  and  the  provider's  NEONS  database 
appears  as  if  both  processes  were  running  on  one  hardware  system;  inter  process  communication  is 
transparent  to  the  user  (except  for  network  bandwidth/loading  considerations). 

Future  Research:  The  prototype  was  developed  for  the  NEONS  volumetric  data  type  to  satisfy  the 
immediate  needs  of  TO  WAN  project  participants.  The  interface,  however,  is  largely  independent  of 
data  organization,  type,  and  range,  and  assumes  only  that  latitudes  and  longitudes  increase  from  west 
to  east  and  south  to  north,  respectively.  It  should  therefore  be  relatively  straightforward  to  modify  the 
system  to  support  other  I^ONS  data  types  (grid,  iatitude/longitude/time,  line  and  image).  The  grid 
data  type  is  a  particularly  good  candidate  since  it  was  the  precursor  of  the  volumetric  data  type. 
Furthermore,  the  interface’s  only  requirement  for  the  BROWSER  is  for  identification  of  a  unique 
volumetric  data  array.  This  requirement  could  be  equally  satisfied  by  an  extension  of  the  extraction 
interface,  making  the  retrieval  code  an  independent  application. 

Research  Advisor:  Mr.  Michael  S.  (Steve)  Foster,  Center  for  Air  Sea  Technology,  Mississippi  State 
University. 
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Michael  S.  Baer,  IV 

Program,  USM  Cooperative  Education  Program 
University  of  Southern  Mississippi 

Project  #1  Title:  Implement  a  Geophysical  Database  Using  the  Oracle  Relational  Database 
Management  System  (RDBMS) 

Objectives:  To  reconfigure  existing  geophysical  applications,  built  using  the  Empress 
monolithic  RDBMS,  to  use  the  Oracle  client  server  RDBMS. 

Approach:  Install  the  Oracle  database  and  configme  it  to  work  with  existing  hardware.  Then 
acquire  skills  to  create,  maintain,  and  administer  the  RDBMS.  The  next  step  is  to  create  the 
database  so  that  data  will  be  stored  logically  and  efEciently.  After  these  tasks  have  been 
accomplished,  NEONS  software  developed  to  run  on  the  Oracle  RDBMS  must  be  installed  on 
the  database.  Next,  CAST  upgrades  used  on  NEONS  for  Empress,  must  be  added  to  this  new 
NEONS  software  package.  Lastly,  existing  database  applications  must  be  ported  to  use  this  new 
software. 

Results:  Oracle  was  installed  at  CAST  on  a  Sun  Sparc  1  Workstation.  Extensive  knowledge  of 
the  Oracle  client  server  RDBMS  has  been  gained  at  CAST  by  hands  on  experience  and 
experimentation.  NEONS  for  Oracle  has  also  been  installed  on  this  system  and,  after  altering 
Oracle  NEONS  to  incorporate  all  of  the  CAST  upgrades,  a  CAST  Data  Browser  was  ported  to 
use  the  Oracle  NEONS  software.  The  Browser  port  was  successful  and  other  CAST  applications 
will  now  be  poned  to  use  this  software. 

Project  #2  Title:  Flat  File  Feature  of  Real  Time  Wave  Forecasting  System  (RTWF) 

Objective:  To  create  a  function  on  the  RTWF  that  will  allow  the  user  to  import  data  from  a  flat 
file  instead  of  the  database. 

Approach:  Develop  an  algorithm  that  will  efficiendy  search  flat  files.  To  increase  efficiency, 
the  algorithm  will  eliminate  unnecessary  file  reads.  This  algorithm  will  then  be  incorporated  into 
a  C  language  function.  After  testing  and  evaluation,  this  function  will  be  included  in  the  RTWF 
application. 

Results:  An  algorithm  was  developed  that  allowed  the  flat  file  to  be  searched  with  a  minimum 
number  of  file  reads.  After  testing,  the  application  was  incorporated  into  the  RTWF  application. 

4!  Ik  :|c  4!  I|t  4!  3)1  3fc  4c  9|<  4c  :i<  4: 4c  4c ’ll  41  lie  4c  *  *  <1 ’ll  4c  %  !|c  :|c  *  !|C  4c  *  4c  ^  *  4c  4c  :|c  :|c  9|( 

Project  #3  Title:  The  World  Weather  Watch  (WWW)  Chartwall 

Objective:  To  simulate  a  chart  wall  of  maps  on  a  computer  by  creating  a  graphical  user 
intafare  (GUI)  that  contains  icons  of  these  maps. 

Approach:  To  develop  this,  the  X- Window  system  using  the  OSF  Motif  toolkit  was  studied  to 
gain  the  knowledge  necessary  to  incorporate  these  tools  into  the  application.  After  a  thorough 
understanding  of  X  has  been  achieved,  the  developer  then  creates  a  program  to  convert  the 
weather  maps  from  their  TIFF  format  to  an  Xpixmap  format  that  may  be  placed  on  top  of  push 
button  widgets.  Pushbuttons  widgets  with  these  images  on  them  will  then  be  created  in  a  GUI  in 
such  a  way  that  when  the  buttons  are  selected  by  a  user,  they  will  call  up  a  routine  to  display  the 
original  weather  map  in  its  full  screen  version. 
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Results;  The  application  was  developed,  tested,  and  has  been  incorporated  into  the  WWW 
application. 


**  i|t  4i  4>  Ik  4i  Ik  4t  *  4i  **  **  *******  *******  * 

Project  #4  Title:  CAST  Model  Evaluation  System  (CMES)  Documentation 

Objective:  levelop  documentation  for  the  CMES  using  Mosaic  software. 

Approach:  To  obtain  an  understanding  of  CMES  and  its  various  applications,  and  then  to  create 
an  online  (internet)  user  manual  for  CMES  using  hypertext  linked  documents  in  Mosaic. 
Documents  which  explain  all  aspects  of  CMES  will  be  created,  and  divided  into  logical  sections. 
These  sections  each  represent  one  Mosaic  page.  On  these  pages  there  will  be  graphics  and 
highlighted  words.  The  highlighted  words  will  be  hyperlinks  to  other  pages.  X  window  dumps 
of  various  CMES  user  screens  will  be  created  and  the  graphics  will  be  inserted  into  the 
hyperlinked  pages.  These  graphics  will  then  be  given  “hotspots”  that  will  act  as  hyperlinks  to 
other  pages.  These  features  will  make  the  documentation  interactive. 

Results:  A  full  understanding  of  CMES  has  been  acquired  and  clear  concise  documentation  for 
CMES  has  been  developed  using  Mosaic. 

Research  Advisor:  Mr.  Ramesh  Krishnamagaru,  Center  for  Air  Sea  Technology,  Mississippi 
State  University. 
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Arun  Sridharan 
Program,  School  of  Physics 
Brandeis  University 

Title;  Computer  Applications  to  Geophysical  Sciences 

Objective:  To  explore  different  areas  of  computer  science  and  understand  how  computer 
technology  can  be  used  in  geophysical  sciences,  and  to  assist  CAST  in  investigating  new 
softwares. 

Approach:  Current  research  in  oceanography  requires  the  extensive  use  of  computers.  Any 
software  that  is  used  to  analyze  oceanographic  data  must  be  able  to  access  information  from  a 
database,  have  a  user  friendly  interface,  and  be  able  to  display  the  data  in  a  graphical  format 
using  an  {q)propriate  model.  To  understand  the  software,  I  studied  graphical  u:er  interfaces, 
relational  datab^s,  and  networking. 

Initially,  I  learned  the  C  programming  language  and  many  of  the  intricacies  of  the  UNIX 
operating  system,  and  wrote  several  example  programs.  Next,  I  learned  X  programming  and 
how  to  use  the  MOTIF  widget  set  to  create  widgets  serving  different  functions.  To  gain  more 
than  a  theoretical  understan^g  of  X  programming,  I  also  wrote  sample  programs  that  involved 
several  conveniences  as  well  as  Xt  functions.  ITiis  included  experimentation  with  the  text, 
pushbutton,  bulletin  board,  dialog,  and  form  widgets.  Then,  in  addition  to  writing  programs  with 
graphical  user  interfaces  in  C,  I  learned  how  to  use  Empress,  a  relational  datable  system.  To 
better  understand  how  information  in  tables  within  Empress  can  be  accessed  by  an  application 
written  in  C,  I  wrote  programs  to  open  and  close  tables,  retrieve  data  and  stored  them  in  different 
vanables,  manipulate  the  data,  and  write  data  back  into  the  tables. 

One  goal  was  to  write  an  application  that  retrieved  information  from  a  database,  manipulated  the 
data,  and  allowed  the  user  to  choose  various  operations  to  be  performed  on  the  data  in  a  user 
friendly  manner.  Here,  I  created  pushbutton  widgets  within  a  window  that  allowed  the  user  to 
add,  delete,  or  view  information  in  the  database.  Next,  I  opened  the  database,  retrieved  the 
infcnmation  and  stored  it  in  a  doubly  linked  list  of  structures.  When  the  user  clicked  one  of  the 
options,  program  control  would  1^  transferred  to  a  function  that  either  added,  deleted,  or 
displayed  the  database.  This  utility  was  used  to  extract  ocean  model  data  from  the  database  and 
to  evaluate  a  new  graphics  utility  called  ARC  INFO.  ARC  INFO  is  a  geographical  infonnation 
system  employed  as  a  standard  graphics  package  at  the  Naval  Oceanographic  Office.  Another 
effort  was  to  develop  the  filters  to  convert  the  database  to  ARC  INFO  format. 

Results:  The  program  developed  is  user  friendly  in  that  all  the  options  are  mouse  driven.  A  user 
does  not  need  to  know  how  a  relational  database  works,  and  can  easily  add,  delete,  and  view 
information  in  a  database  over  a  network  without  knowing  how  the  different  C  functions  used 
correlate  with  one  another.  Finally,  AML  based  ARC  INFO  scripts  were  developed  to  do  grid 
displays. 

Future  Research;  Could  involve  translating  the  C  code  into  C-h-  and  using  a  different  database 
such  as  Oracle. 

Project  Advisor:  Mr.  Ramesh  Krishnamagaru,  Center  for  Air  Sea  Technology,  Mississippi 
State  University. 
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Clifton  Abbott 

Program,  MSU  Cooperative  Education  Program 
Mississipia  State  University 

Project  #1  Title:  CAST  Model  Evaluation  System  (CMES)  Functions 

Objectives:  To  add  import,  export,  and  volume  functions  to  the  CMES. 

Approach:  The  NEONS  BROWER  already  had  a  volume  function  running,  and  this  function 
was  transferred  and  tailored  to  fit  the  CMES. 

The  import  and  export  functions  for  CMES  were  provided  in  four  different  file  formats.  The 
first  format  provided  was  ASCII,  which  was  divided  into  two  formats,  text  and  binary.  These 
formats  were  decided  by  the  extension  of  the  filename,  .dat  or  .bin.  Another  format  provided 
was  the  HDF  format.  The  last  format  to  be  completed  at  a  later  data  is  the  NetCDF  format. 

Results:  The  various  functions  were  added,  tested,  and  integrated  into  the  CMES. 


Project  #2  Title:  CAST  Model  Evaluation  System  (CMES)  Formats 

Objectives:  To  transfer  CMES  from  Kemghan  and  Ritchie  (k&r)  format  to  the  ANSI  format. 

Approach:  The  main  difference  between  k&r  and  ANSI  was  in  the  function  prototyping.  All 
functions  had  to  be  prototyped  with  parameters  fully  declared  within  their  types.  Witii  ANSI’s 
strong  type  checking,  sevei^  parameters  had  to  be  type  casted  when  being  passed  to  a  function 
or  being  used  in  a  structure.  Along  with  the  ANSI  format,  CMES  was  transported  to  a  SGI 
platform  to  make  it  more  portable. 

Results:  CMES,  with  all  functions  prototyped,  was  compiled  on  a  SGI  as  ANSI  code.  CMES 
was  also  moved  back  to  the  standard  Unix  platform  and  compiled  as  ANSI  code. 

Future  Research:  CMES  in  its  ANSI  format  will  eventually  reside  on  the  ISIS  database  instead 
of  the  NEONS  database. 

Research  Advisor:  Mr.  Ramesh  Krishnamagaru,  Center  for  Air  Sea  Technology,  Mississippi 
State  University. 
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